Data communication in a computer network involves the exchange of data between two or more entities interconnected by communication links and subnetworks. These entities are typically software programs executing on hardware computer platforms, which, depending on their roles within the network, may serve as end stations or intermediate stations. Examples of intermediate stations include routers, bridges and switches that interconnect communication links and subnetworks; an end station may be a computer located on one of the subnetworks. More generally, an end station connotes a source of or target for data that typically does not provide routing or other services to other computers on the network. A local area network (LAN) is an example of a subnetwork that provides relatively short-distance communication among the interconnected stations; in contrast, a wide area network (WAN) facilitates long-distance communication over links provided by public or private telecommunications facilities.
End stations typically communicate by exchanging discrete packets or frames of data according to predefined protocols. In this context, a protocol represents a set of rules defining how the stations interact with each other to transfer data. Such interaction is simple within a LAN, since these are typically “multicast” networks: when a source station transmits a frame over the LAN, it reaches all stations on that LAN. If the intended recipient of the frame is connected to another LAN, the frame is passed over a routing device to that other LAN. Collectively, these hardware and software components comprise a communications network and their interconnections are defined by an underlying architecture.
Most computer network architectures are organized as a series of hardware and software levels or “layers” within each station. These layers interact to format data for transfer between, e.g., a source station and a destination station communicating over the network. Specifically, predetermined services are performed on the data as it passes through each layer, and the layers communicate with each other by means of the predefined protocols. This design permits each layer to offer selected services to other layers using a standardized interface that shields the other layers from the details of actual implementation of the services.
The lower layers of these architectures are generally standardized and implemented in hardware and firmware, whereas the higher layers are usually implemented in the form of software. Examples of such communications architectures include the Systems Network Architecture (SNA) developed by International Business Machines (IBM) is Corporation and the Internet communications architecture.
The Internet architecture is represented by four layers termed, in ascending interfacing order, the network interface, internetwork, transport and application layers. The primary internetwork-layer protocol of the Internet architecture is the Internet Protocol (IP). IP is primarily a connectionless protocol that provides for internetwork routing, fragmentation and reassembly of exchanged packets—generally referred to as “datagrams” in an Internet environment—and which relies on transport protocols for end-to-end reliability. An example of such a transport protocol is the Transmission Control Protocol (TCP), which is implemented by the transport layer and provides connection-oriented services to the upper layer protocols of the Internet architecture. The term TCP/IP is commonly used to denote this architecture.
SNA is a communications framework widely used to define network functions and establish standards for enabling different models of IBM computers to exchange and process data. SNA is essentially a design philosophy that separates network communications into seven layers termed, in ascending order, the physical control layer, the data link control layer, the path control layer, the transmission control layer, the data flow control layer, the presentation services layer, and the transaction services layer. Each of these layers represents a graduated level of function moving upward from physical connections to application software.
In the SNA architecture, the data link control layer is responsible for transmission of data from one end station to another. Bridges are devices in the data link control layer that are used to connect two or more LANs, so that end stations on either LAN are allowed to access resources on the LANs. Connection-oriented services at the data link layer generally involve three distinct phases: connection establishment, data transfer and connection termination. During connection establishment, a single path or connection, e.g., an IEEE 802.2 Logical Link Control Type 2 (LLC2) connection, is established between the source and destination stations. Once the connection has been established, data is transferred sequentially over the path and, when the LLC2 connection is no longer needed, the path is terminated. Reliable communication of LLC type 2 is well-known and described by Andrew Tanenbaum in his book Computer Networks, Second Edition, published in 1988, all disclosures of which are incorporated herein by reference, especially at pages 253-257.
FIG. 1 is a schematic block diagram of a conventional computer network 100 having a source end station ESA coupled to token ring (TR) network TR1 and a destination end station ESB coupled to TR4. The TR networks are of a type that support source-route bridging (SRB) operations with respect to the contents of a routing information field (RIF) of a frame. An SRB bridge B1 further interconnects TR1 and TR2, while SRB B3 interconnects TR4 and TR3; SRB bridge B2 then couples TR2 to TR3. The SRB network 100 essentially functions as a LAN because there is no WAN cloud disposed within the network.
End stations ESA and ESB communicate by exchanging TR frames over LLC2 connections or sessions through the SRB network. Each TR frame 110 includes a RIF 112 that contains source route information in the form of ring number/bridge number pair “hops” within a path between the source and destination end stations. For example, the RIF 112 of TR frame 110 transmitted by ESA to ESB contains <0011.0022.0033.0040>. A control field 114 appended to the RIF 112 of the frame 110 specifies the type of TR frame; one type of frame is a spanning tree explorer (STE) frame having control field contents of <CA70>. An LLC2 session is established between the end stations using a special TR frame, such as the STE frame.
Specifically, the STE frame is used by a source (e.g., ESA) to “discover” the path to a destination (e.g., ESB); thereafter, a set asynchronous balanced mode extended (SABME) frame is sent from ESA to ESB to establish a logical connection between the endstations, and ESB responds to the SABME frame with an unnumbered acknowledgment (UA) frame. Once the UA frame is received by ESA, a connection is established between the source and destination, and these end stations communicate by exchanging TR information (INFO) and acknowledgement frames until the logical link session is completed.
For example, ESA transmits an INFO frame over TR1 and through the various bridges and rings to ESB. Upon successfully receiving the INFO frame, ESB responds by transmitting an LLC2 Receive/Ready (RR) acknowledgment frame over the SRB network to ESA. This INFO/RR exchange continues until ESA has successfully transmitted all of its data and ESB has successfully received all of that data. Session completion is then initiated by a disconnected mode (DM) frame being transmitted from ESA to ESB; the disconnection is thereafter acknowledged by ESB responding with a UA frame. The LLC2 frames (packets) are described by Radia Perlman in her book Interconnections, Bridges and Routers, published by Addison Wesley Publishing Company, in 1992, all disclosures of which are incorporated herein by reference, particularly at pages 33-34.
As noted above, each TR INFO frame sent from a source to a destination is acknowledged by an RR frame; if the source end station does not receive the acknowledgment frame within a prescribed period of time, a “time-out” occurs and the source sends a DM frame to prematurely terminate the session. Since the network 100 is a LAN, it facilitates fast transfer of information between its connected stations and, as a result, a time-out condition should rarely occur. If a WAN, such as a Transmission Control Protocol/Internet Protocol (TCP/IP) cloud, is disposed within a LAN-based network, it is likely that a time-out will arise because of the latencies introduced by the TCP/IP cloud. That is, a frame traversing the WAN cloud incurs substantial delay as opposed to the LAN because the WAN is generally not as fast as the LAN.
Data link switching (DLSw) is a mechanism for forwarding SNA and Network Basic Input Output Services (NetBIOS) protocol frames over a TCP/IP backbone WAN, such as the Internet. In traditional bridging, the data link connection is end-to-end, i.e., effectively continuous between communicating end stations. A stream of data frames originating from a source end station on a source LAN traverses one or more bridges specified in the path over the LLC2 connection to a destination station on a destination LAN. In a network implementing DLSw, by contrast, the LLC2 connection terminates at a local DLSw device, e.g., a switch. An example of a DLSw network arrangement may comprise one or more local DLSw devices connected to a local LAN having a source end station and a remote DLSw device connected to a remote LAN having a destination end station. The LANs that are accessed through the DLSw devices may appear as SRB subnetworks attached to adjacent rings; each of these adjacent rings manifest as a virtual ring within each DLSw device that effectively terminates the SRB subnetwork.
FIG. 2 is a schematic block diagram of such a DLSw network 200 having a TCP/IP cloud 210 disposed between local and remote SRB subnetworks 202, 204. When communicating with ESB as described above, ESA sends an INFO frame to which ESB responds with an RR frame. Because of the latencies introduced by the WAN cloud, however, a time-out condition occurs during this exchange. To solve this problem, the DLSw network includes local and remote DLSw devices that border the WAN cloud; these DLSw devices function as endpoints between TCP sessions over the TCP/IP WAN cloud when transporting TR frames associated with LLC2 sessions over that intermediate cloud. DLSw switching obviates the time-out problem introduced by the TCP/IP network by, e.g., having the local DLSw switch return a RR acknowledgment frame to the source end station upon receiving an INFO frame. Notably, the RR frame is returned prior to transmitting the native TR INFO frame over the TCP/IP network.
Broadly stated, each DLSw device establishes a “peer” relationship to the other DLSw device in accordance with a conventional capabilities exchange message sequence, and the logical and physical connections between these devices connect the subnetworks into a larger DLSw network. To establish a DLSw peer connection, the local DLSw device first opens logical TCP (read/write) “pipe” connections to the remote DLSw device using a conventional socket technique to create a socket into the transport layer of the protocol stack. Once the TCP pipes are established, a switch-to-switch (SSP) protocol is used to transport the capabilities exchange messages between the two DLSw devices.
The capability exchange messages contain various parameters, such as the number of pipes used for communicating between the DLSw devices and the largest frame size supported by the devices. Each DLSw device responds to each capability exchange message issued by its peer device with a capability exchange response message. Upon completion of the exchange, each device reconfigures itself to “act upon” the agreed capabilities and the peer connection is established. Establishment of a peer connection occurs automatically upon “boot-up” of each DLSw device; that is, as soon as a DLSw device activates, it connects with its DLSw peer. The DLSw forwarding mechanism is well-known and described in detail in Wells et al., Request for Comment (RFC) 1795 (1995).
Upon receiving a TR frame from a source on the local SRB subnetwork, the local DLSw device employs the SSP protocol to communicate with its DLSw peer device by forwarding the native TR frame over the TCP/IP network to a remote SRB subnetwork. That is, the TR frame received at the local DLSw switch from the source is encapsulated within a SSP protocol frame and forwarded over the TCP/IP WAN to the remote DLSw switch. Notably, the source route information contained in the RIF of each TR frame also terminates inside the virtual ring of the DLSw switch. That is, the encapsulated SSP frame does not contain any source route information from the source to the local DLSw switch.
The local DLSw device then multiplexes the LLC2 data stream over a conventional TCP transport connection to a remote DLSw device. LLC2 acknowledgement frames used to acknowledge ordered receipt of the LLC2 data frames are “stripped-out” of the data stream and acted upon by the local DLSw device; in this way, the actual data frames are permitted to traverse the IP WAN to their destination while the “overhead” acknowledgement frames required by LLC2 connections for reliable data delivery are kept off the WAN. The LLC2 connections from the source LAN to the local transmitting DLSw device, and from the remote receiving DLSw device to the destination LAN, are entirely independent from one another. Data link switching may be further implemented on multi-protocol routers capable of handling DLSw devices as well as conventional (e.g., SRB) frames.
The remote switch decapsulates the SSP frame to recover the native TR frame is and, if it has “cached” (i.e., stored) routing information from the remote switch to a destination on the remote SRB subnetwork, it loads the RIF of the frame with this information. Thus, the routing information loaded into the RIF starts from the virtual ring of the remote DLSw device and does not contain the source route information from the source endstation on the local SRB subnetwork. As a result, a TR frame cannot be transparently forwarded from a local SRB subnetwork to a remote SRB subnetwork over a DLSw network merely based upon the RIF of the TR frame.
FIG. 3 is a logical flow diagram illustrating establishment of a DLSw session over the DLSw network 200. After the DLSw peer connection is established, ESA transmits an explorer frame, known as a test poll (TEST P) frame, over the connection to discover the destination ESB. The TEST P frame includes, inter alia, a RIF with a control field having the contents of <C270>which denotes a broadcast explorer frame, wherein the direction bit is zero indicating a forward interpretation of the RIF. The TEST P frame is sent by ESA to discover the medium access control (MAC) address of ESB. The TEST P frame is issued by ESA to the local DLSw device, which then transposes that frame into an SSP frame format for transmission over the WAN cloud.
Specifically, the local DLSw device translates the TEST P frame into a can-you-reach (CUR_ex) frame for transmission over the TCP/IP cloud. As noted, the contents of the RIF terminate on a virtual ring within the local DLSw device; as shown in FIG. 2, the virtual ring is assigned ring number 4095 (FFF hex) and the DLSw device is assigned bridge number 1. Therefore, when the local DLSw device receives the TEST P frame, the frame has traversed two token rings and a bridge; accordingly, the RIF contents comprise 6-bytes of routing information <C670.0011.FFF0>, wherein the control header contents are <C670>. The RIF information contained in the frame is stored locally in the local DLSw device prior to that device transmitting the CUR_ex frame over the TCP/IP cloud.
When constructing the CUR_ex frame, the local DLSw device inserts into the header of the SSP frame information such as the destination MAC (DMAC), source MAC (SMAC), destination service access point (DSAP) and source SAP (SSAP) that it extracted from the TEST P frame. The CUR_ex frame is then transmitted over the TCP/IP cloud and received at the remote DLSw device. Note that the local SRB network terminates at the local DLSw device and another remote SRB network is formed on the other side of the WAN at the remote DLSw device, which is assigned a bridge number of 2 and a virtual ring number 4094 (FFE hex).
Upon receiving the CUR_ex frame, the remote DLSw device translates that frame into a TEST P frame using the DMAC, SMAC, DSAP, SSAP and other pertinent information. The remote DLSw device also inserts into the RIF the following routing information: <FFE2.0020>. The BN0 associated with RN002 of the RIF denotes that the destination (ESB) is coupled to the ring RN002. In response to receiving the TEST P frame, ESB returns a test final (TEST F) response frame that is received by the remote DLSw device; the remote DLSw device translates the TEST F frame into an I-can-reach explorer (ICR_ex) frame that is transmited over the TCP/IP cloud to the local DLSw device. The ICR_ex frame is similar in format to the CUR_ex frame; that is, both frames incorporate the SSP protocol along with the necessary information from the TR frame. Upon receiving the ICR_ex frame, the local DLSw device generates a TEST F frame for transmission to ESA. The TEST F frame incorporates information locally stored at the local DLSw device as a result of the initial TEST P frame issued by ESA. Notably, the local DLSw device correlates the ICR_ex frame with the locally-stored information using the DMAC, SMAC, SSAP and DSAP information.
In response to receiving the TEST F frame, ESA examines the RIF and formulates a simple view of a path to ESB comprising a 2-ring SRB network. In other words, ESA examines the RIF of the TEST F frame and determines that the path to ESb comprises RN1, BN1 and RN4095. ESA then initiates a conventional XID message exchange (defined by the SNA protocol) with ES8. Broadly stated, ESA sends an XID null poll (NULL P) frame to ESB that is received by the local DLSw device and interpreted as a request to establish a DLSw circuit over the TCP/IP network. In response to the NULL P frame, the local DLSw device issues a can-you-reach circuit start (CUR_cs) frame to the remote DLSw device; the CUR_cs frame is an initiate circuit setup message.
Since the remote DLSw device has previously reached ESB (and has cached the previous TEST P/F information), it returns an I-can-reach circuit start (ICR_cs) frame to the local DLSw device in response to the CUR_cs frame. Upon receiving the ICR_cs message, the local DLSw device issues an acknowledgment (REACH_ACK) that is received by the remote DLSw device and which places the DLSw switches into a circuit establishment state. The XID NULL P that was previously sent from ESA to the local DLSw device has not yet been transported over the IP and has, in fact, been cached at the local DLSw device. Upon establishing the SSP circuit over the IP WAN, the DLSw devices generate a correlator that correlates the SNA LLC circuit to the established SSP circuit. The correlator may be substituted for the DMAC, SMAC, DSAP, SSAP format that had been used to correlate frames from the SRB network over the TCP/IP cloud.
Thereafter, the local DLSw device sends the cached XID NULL P frame over the TCP/IP circuit to the remote DLSw device. This frame assumes the form of an XIDFRAME having an SSP format but with the data portion of the XID NULL P frame. That is, the local DLSw device “strips-off” the header of the XID NULL P frame and loads the remaining data portion into the XIDFRAME for transmission over the TCP/IP network to the remote DLSw device. At the remote DLSw device, the XIDFRAME is converted back to an XID NULL P message with a RIF that includes routing information previously cached at the remote device and that identifies the route to ESB. ESB responds with an XID frame that is translated by the remote DLSw device into an XIDFRAME for transmission over the TCP/IP network. Upon receiving this latter frame, the local DLSw device translates it into an XID frame and loads the RIF with the locally cached routing information to ESA; the local DLSw device then transmits the XID frame to ESA. Thereafter, after, an XID frame exchange occurs between the endstations to establish an end-to-end circuit connection with negotiated and agreed-upon parameters defining that connection.
Upon reaching a mutually agreeable set of parameters for a connection, ESA transmits a SABME frame to initiate establishment of an actual session for transferring data between the endstations. The local DLSw device receives the SABME frame and transitions to a connect pending state wherein it translates the SABME message into a CONTACT frame for transmission over the TCP/IP network cloud. The remote DLSw device receives the CONTACT frame and translates it into a SABME frame for transmission to ESB. This is essentially the first attempt to establish an actual connection across the TCP/IP cloud from either end of the SRB network. ESB responds to the SABME frame with a UA frame that, upon being received by the remote DLSw device, is translated to a CONTACTED frame for transmission over the TCIP/IP cloud; the remote DLSw device then transitions to a connected state. Similarly, upon receiving the CONTACTED frame, the local DLSw device enters a connected state and translates the received frame into a UA frame for transmission to ESA. When ESA receives the UA, a DLSw session is established and ESA begins transmitting information frames (IFRAMEs) that are translated into INFO_FRAMEs at the DLSw devices for transmission over the IP cloud. The IFRAMEs contain the actual data transferred between the end stations.
Although an end-to-end session is established between end stations, the end stations do not have a complete view of the route between them. That is, the source route information contained within the RIF of a TR frame issued by a source end station over the local SRB network is cached at the local DLSw device and is not present in the RIF of the TR frame transmitted by the remote DLSw device over the remote SRB network. Correlators are used to associate the local and remote SRB routes over the TCP/IP connections between the DLSw devices.
Some applications require transparent forwarding of a TR frame from a source to a destination via the DLSw devices based on the end-to-end RIF. For example, a remote network control protocol (NCP) load application loads an image of an NCP program executing on a source front end processor (FEP) to a destination FEP. Remote NCP load is a protocol that is tailored towards loading the NCP image in a remote station and cannot function in a conventional DLSw network environment because the remote NCP load protocol does not accommodate the exchanges required to establish a connection in a DLSw network; i.e., it is not a connection-oriented protocol. Therefore, current DLSw networks do not support applications such as remote NCP load, LAN manager or redundant explorer filtering. The present invention is directed to a technique that allows applications such as remote NCP load to be executed over a DLSw network.